1. Field of the Invention
The present invention relates to computer implemented systems and methods for creating a security-enhanced report containing information useful to multiple users. More specifically, the invention relates to systems and methods for generating and displaying a table of content for the security-enhanced report.
2. Discussion of Related Art
Many enterprises and organizations today often deal with large amounts of data in the form of reports. The number of reports in a particular organization can vary from dozens to thousands of various types and to levels of employees. It is often the case that some employees in an enterprise are authorized to view certain data while other employees, typically those at a higher level, can see more data than those who report to them. Security with respect to which employees are authorized to see certain data has become an increasingly complex task to manage. For example, executive employees can see more types of data items than other employees in the corporation but the rules as to who can see what are constantly changing. This is made more complex by the high employee turnover rate at many large corporations.
Generally, techniques presently in use to address security needs at large organizations involve two ways of dealing with data security and reports. One method widely used can be referred to generally as a code-based method in which the format and contents of the report are essentially determined through a custom-written program in a language such as Cobol or some other language typically used in large data processing environments. A traditional way to implement xe2x80x9cpage securityxe2x80x9d with paper reports, for example, is to print one large report. Sections of pages in the report contain visible headers that indicate who receives that section. An employee goes through the report and xe2x80x9cburstsxe2x80x9d it into separate printed sections. These sections are then sent to the particular users. Historically, it was cheaper to have a person perform the bursting than to have it done by the computer. One advantage of a code-based technique is that there is significant flexibility with respect to formatting and determining what data will be in a particular report. However, such code-based reports require specialized knowledge of the custom-written program in the particular programming language. This lack of flexibility with respect to making updates and general maintenance of the program is a significant constraint.
Another technique used to generate reports having security features can be referred to as the user-interface (UI) driven process. With UI-based report generation, users essentially fill-in blanks on the screen to generate a particular report. The advantage to using a UI-based report generator is that it is generally easy for a user to generate a report. But, to keep the UI easy to use, most tools omit advanced features such as security. The user simply tells the program where certain text or data should be placed or formatted in a particular report. However, the drawbacks are significant in that such UI-based report generators do not have the flexibility or features to allow for different types of reports or different formatting because the user interface itself is preprogrammed.
As stated above, security with respect to which users can see particular portions of data is a particularly complex issue in large companies. In order to address the security issue, in some situations a company would typically run a single printed report and perform the physical bursting of the pages as described above. For example, a company would execute a report executable for the East, West, and Central regions and have different security rules for each report. Such report executables would typically be stored on a report server and would be executed periodically throughout the day. Essentially, different reports and files would be generated and security features would be attached to each one.
In many cases, a significant issue with running multiple reports in a given day is ensuring that the correct data is contained in each report and that the large set of reports are managed properly. It is not unusual for the number of reports to reach the hundreds or thousands in a single day. This can lead to complex maintenance issues and create an error-prone environment. This is especially true if security rules change for any of the reports or if the time a particular report should run has to be changed. In addition, running a large volume of report executables every day also requires high utilization of an organization""s computer resources.
Another practice used in implementing security based on what individual users can see is creating xe2x80x9cviewsxe2x80x9d of a database by modifying a query with appropriate restrictions on what fields and tables, for example, a user can see. These restrictions are often implemented with specific SQL statements in a data retrieval instruction. A report based on a particular view in which the report only contains data in that view is created. A user""s access to a report is then restricted to that view or a subset of that view if more restrictions are in place. Defining views of a large report is one technique used in solving the security issue.
However, there are several drawbacks with using database views for report security. One disadvantage is that the database for which a view is created has to be accessed each time the user tries to view a report. Alternatively, a database subset must be created for each possible secure view of the data (i.e. report) resulting in a proliferation of persistent objects in the system, eventually matching the number of possible reports. Another drawback is that the calculations and formatting instructions for a view (i.e. report) have to be done each time the user views the report and cannot be cached in advance. Yet another disadvantage of using views to create security-enhanced reports is that the user is not able to view control break or summary information from rows that they are not permitted to view on an individual level. For example, a manager should be allowed to see summarized sales figures from other departments while not allowed to see the detailed sales information from those departments. Using views to create reports, the manager is not able to see even the non-restricted summarized sales figures.
Therefore, it would be desirable to minimize computer resource utilization and reduce the complexities of managing report generation by having one large report with enhanced security features. It would desirable that such a report have different security rules apply to different categories or groups of data printed in the report. It would also be desirable to have the user believe that he or she is receiving an individual, customized report. In other words, it would be desirable that the security and logical xe2x80x9cburstingxe2x80x9d of the report be transparent to the user.
According to the present invention, methods, apparatus, and computer program products are disclosed for generating and viewing an electronic report having security features that allow for xe2x80x9cvirtual burstingxe2x80x9d of the report for multiple users. A single report having multiple pages is generated such that each or some of the pages have security tags that are compared to a security identifier list of a particular user that acts as a security clearance for that user. Through this comparison, a subset of pages from the report is formed which makes up a xe2x80x9creportxe2x80x9d from the user""s point of view that contains only data the user is allowed to see.
In one aspect of the present invention, a method for creating a report having security based on content of the data contained in the report is described. A data row from a data source which is to be xe2x80x9cprintedxe2x80x9d or displayed in the report is retrieved. The data source can be a flat file, a relational database, or other data storage component. It is then determined whether data in the data row causes a level or group break in the report. If the data row causes a level break, a new page in the report is created and a new security tag is formed using information about the new level break. A new page will also be created if the maximum amount of data is on a page (i.e., the bottom margin of a page is reached). The new security tag is then associated with the new page on which the data row is displayed or printed. If the data row does not cause a level break, the data is printed on the existing page in the report and nothing is done to the security tag. Subsequent data rows are retrieved and printed on pages having the new security tag until one of the data rows causes a level break in the data. At this stage a new page is formed and another security tag is created in the same manner as the previous one. Through this process data in the report can be presented to users based on the security tags associated with the pages.
In a preferred embodiment a security identifier for each level break is obtained wherein each level break contains the retrieved data row thereby obtaining one or more security identifiers. The security identifiers are then combined thereby creating a security tag. In another embodiment the step of associating the security tag with a new page in the report involves taking a role (e.g., xe2x80x9cEastern Region Sales Managerxe2x80x9d or xe2x80x9cVice President of Marketingxe2x80x9d) as used in an associated security system and associating it with a data row. Security identifiers (e.g., names of level breaks or groups) in the tag are mapped with one or more roles adopted from the security system thereby creating a security tag usable by the security system. This usable security tag is then associated with one or more pages in the report. In another embodiment data is retrieved from a data source wherein data in the data source is sorted based on one or more level breaks wherein a level break is caused by a change in category of data. In yet another embodiment it is determined whether there is a role in the security system that corresponds directly to the user. It is then determined whether there are any secondary roles that correspond indirectly to the user. The roles are then combined to create a list of security identifiers that acts as a security clearance for the user. This security clearance is then compared to the security tag to derive a subset of pages in the report that can be viewed by a user.
In another aspect of the invention, a method of a user viewing a report having page-level security in the form of a security tag associated with pages in the report such that a user can only view certain data is described. A report having multiple pages where each page has a security tag. A list of security identifiers associated with a user is created or obtained. This can be done through access to a security system. This list of security identifiers is then compared with security tags associated with pages in the report. Through this comparison, a subset of pages from the superset of pages is derived such that the subset of pages only contains data that the user is authorized to view. This is done by comparing the list of security identifiers for the user with the security tags of the pages.
In one embodiment the subset of pages is presented as a stand-alone report created for the user and, as such, has renumbered pages in which the first page of the subset is page one and subsequent pages are renumbered consecutively. In another embodiment the security tag includes level-break identifiers that can be mapped to security identifiers in the list of security identifiers associated with the user and derived from a security system. In another embodiment the level break identifiers in the security tags are compared with the identifiers in the list of security identifiers associated with a user. In another embodiment the subset of pages is derived by determining if there is any commonality between the security tag and the list of security identifiers, and including a page in the subset if the security tag and the list of security identifiers pass a threshold level of commonality when compared. In one embodiment the threshold level of commonality is having one term in the security tag and the list of security identifiers in common. In yet another embodiment content information, such as a table of contents for the report having page numbers of sections in the subset of pages is derived. In one embodiment the content information only contains information related to the subset of pages and generally reflects a level break structure of the subset of pages.
In another aspect of the present invention, a method of creating a content listing or table of contents (xe2x80x9cTOCxe2x80x9d) for a report having data breaks is described. A content list structure corresponding to a report containing multiple data items, in which a data item represents a content group, is retrieved. A data item from the retrieved content list structure, in which the data item contains a page range of the pages in the report, is retrieved from the content list structure. It is then determined whether there are any pages allowed to be viewed by the user in the page range of the retrieved data item. It is then determined whether the retrieved data item should be in the content listing. In this manner, only data items that the user is allowed to view has one or more corresponding content line entries in the content listing and, thereby, a content listing specifically tailored for the report the user can view is created.
In a preferred embodiment a page map structure containing information on which pages from the report the user can view is retrieved. The page map structure is a physical page map having multiple physical page cells and is associated with the user and a physical page cell corresponding to a page in the report. In another preferred embodiment, the physical page map is created by comparing a list of security identifiers associated with the user against multiple security tags associated with a page in the report. A value, such as zero or one, is inserted into each physical page cell based on whether the user can view the page. In another embodiment, the content list structure reflects data breaks in the report. The content list structure is a node hierarchy that includes multiple node levels, where a node level corresponds to a data break, and includes multiple content levels where a content level corresponds to a data break. In yet another preferred embodiment, retrieving a data item from the content list structure involves determining a page range for the retrieved data item where the page range indicates pages in a data group. In yet another embodiment, a data item is excluded from the content listing if none of the pages in the page range can be viewed by the user, which can be determined from the physical page map. A data item is included in the content listing if all the pages in the page range can be viewed by the user, thereby giving the data item a content line entry in the content listing.